home *** CD-ROM | disk | FTP | other *** search
- Path: grimsel.zurich.ibm.com!usenet
- From: wgk@zurich.ibm.com (Keith Whittingham)
- Newsgroups: comp.lang.c++
- Subject: Re: unsigned char question
- Date: 8 Mar 1996 08:34:47 GMT
- Organization: IBM Research, ZRH
- Message-ID: <4horf7$oif@grimsel.zurich.ibm.com>
- References: <3136864B.7154@eds.com>
- Reply-To: wgk@zurich.ibm.com
- NNTP-Posting-Host: pine.zurich.ibm.com
- X-Newsreader: IBM NewsReader/2 v1.00
-
- In <3136864B.7154@eds.com>, Perry Hoekstra <lnusmsc.phoeks01@eds.com> writes:
- >This is a basic question but one I cannot answer. I am using VC++ 2.0
- >and I wish to assign a string to a variable of type UCHAR * (which is an unsigned char
- >within ODBC). The code is as follows
- >
- >UCHAR * server;
- >
- >server = "jmbademo";
- >
-
- The other couple of responses to this say "cast" - yes your problem is
- that the types are different, server is unsigned char and "jmbademo" is
- a signed char.
-
- Using UCHAR, LONG, etc. is one of my pet hates: use "unsigned char" or
- "long" instead. It's clearer, it takes less time to compile and
- what do think will happen if someone ever decides to change UCHAR to
- be something other than unsigned char? If you need some kind of data
- type portability use U16 for an unsigned 16 bit, S8 for a signed 8 bit.
- That way you know what your dealing with.
-
- A second no-no is casting your way out of problems. Casting gets rid of
- compiler warnings and errors but is no solution. Worse still a cast
- represents a maintenance problem. Consider:
-
- 1: char *Ptr;
- 2: unsigned char uc;
- 3:
- 4: uc = 0;
- 5: Ptr = (char *)&uc;
- 6: (*Ptr)--;
- 7: cout << uc << endl;
-
- uc has wrapped to 255 as one would expect. Now change line 2 to read
-
- 2: unsigned int uc;
-
- No compiler errors, warnings and not the same answer.
-
- If "server" is a signed char use a signed char otherwise what you're doing
- is problably wrong and it's going to bite back later.
-
- KEith
-
-
-
-
-
-
-
-